package Git2024_5_17;

public class Project1 {
    //项目整体设计--多模块分工合作
    /**
     * 请求的URL地址设计--整体设计
     */
    //HttpClient测试
    /**
     * 文件位置: test/http/Xxx.http
     *
     * 添加测试方法时
     *  1.GET
     *  2.POST
     *      2.1 第一个 JSON格式---POST Test Body
     *      2.2 第二个 <form>表单格式---POST Parameter Body
     *      <form action="" method="post">
     *           <insert type="text" name="username">
     *               \..
     * java前端代码[了解]
     *  1.const data-{
     *                username:xxxx,
     *                password:xxxx
     *                }定义变量--JS对象
     *  2.axios.post('地址',data)---在测试时需要使用POST Test Body方式测试
     *      \..
     */
    /**
     * 1.API文档: 由后端工程师设计 协调前后端工作
     * 2.关于JSON: 一种数据传输格式[通用格式] 使用Spring MVC框架时使用较多
     * 3.Spring MVC执行流程: 请求 -> 前端控制器 -> 处理器映射器[url->Controller] -> 前端控制器
     * -> 处理器适配器[具体的Controller的实现类]
     * -> 处理器控制器[执行Controller->返回ModelAndView] -> 处理器适配器 -> 前端控制器 -> 视图解析器 -> 前端控制器[渲染视图]
     * -> 前端控制器返回响应
     */
    /*------------------------------------------------------正课------------------------------------------------------*/
    /**
     * Transfer
     * 1.什么是RESTful特征的API
     * 2.如何设计符合RESTful特征的API
     *  2.1 关于URL[统一资源定位器]
     *          协议-http 80 https 443[默认端口号]
     *          域名: 尽量体现API字样
     *          版本: 访问路径[path]中最好保留版本控制的信息如../v1/..
     *          路径: 避免使用动词 资源用名词[及其复数]表示
     *  2.2 HTTP动词语义
     *          GET[从服务器取出资源]
     *          POST[向服务器发送资源,创建新资源]
     *          PUT[更新服务器上的资源,常用于替换整个资源]
     *          DELETE[删除服务器上的资源,一般无请求体]
     *  2.3 巧用查询参数
     *          ?查询参数1&查询参数2&\..
     *  2.4 HTTP状态码
     *          三位数 1xx 2xx 3xx 4xx 5xx
     *          常见:
     *          200 服务器成功返回用户请求的数据
     *          404 用户发出的请求针对的是不存在的记录
     *          500 服务器发生错误
     *          405 请求方法不被允许
     *              即在服务端规定了请求的格式[例如POST] 而在客户端 用户使用了其他的请求格式
     * 3.常用注解[详见下述]
     */
    //常用注解详解
    /**
     * 规定请求格式:
     * 方法1.@RequestMapping(value="insert",method = RequestMethod.POST)
     * 方法2.注解Get/Post/Delete/PutMapping("路径")代替传统的RequestMapping("路径")
     */
    /**
     * 传递参数方式
     * 方法1.http://localhost:8080/v1/users/delete?id=1
     * 方法2.http://localhost:8080/v1/users/delete/1[参数1..]
     *      http://localhost:8080/v1/users/delete/2[参数2..]
     *
     * 接收参数方式
     * @GetMapping("路径/{参数名}") 例如@GetMapping("delete/{id}")
     * 并添加注解 声明该参数是在路径中获取的@PathVariable
     * 例如:
     *     @GetMapping("delete/{id}")---路径中为"id"
     *     public String delete(@PathVariable Integer id){---方法中的参数名要与路径中的对应一致
     *         userMapper.deleteUserById(id);
     *         return "删除成功";
     *     }
     */
    //@RequestBody注解
    /**
     * 1.注解联动:
     *  @RequestBody 将JS对象转换为json对象(给到java后端)
     *  @ResponseBody 将java对象转化为json对象(给到JS前端)
     *
     * 2.@RequestBody:
     *  加在参数上 将请求体中的数据转为JSON 再赋值给参数变量
     *
     * 3.应用场景:
     *  请求类型中表明了"json" 例如 application/json 则使用@RequestBody注解进行数据转换
     *  [RequestBody常常在有json提示的情景下使用]
     */
    /**
     * HTTP
     * 是一个无状态的协议 即客户端和服务端的会话仅仅保留在一次请求和一次响应之间 不能进行会话保持
     * 若用户又发送了相同请求 HTTP会将其作为新用户新请求执行
     *
     * 引入外部会话保持技术
     * 1.Cookie(在请求头中,包含大量信息(格式为"key=value"):XXX=Xxx,XXX=xXx...)
     *  过程:
     *   1.客户端 --登录请求[携带用户名,密码等信息]--> 服务端
     *   2.服务器(1)获取,(2)校验信息 ----> 正确,登陆成功
     *   3.服务端 --返会登陆成功响应[通过代码将<把用户标识存入Cookie中>的需求传递给客户端]--> 客户端
     *   4.客户端 --发起需要登录才能访问的请求,如查询订单请求[携带Cookie(包含用户标识,且为<同域自动提交>模式)]--> 服务端
     *   5.服务端(1)获取用户标识,(2)查询用户标识中的有效期是否过期,(3)校验用户差异,(4)查询请求对应信息,(5)返回前端对应数据
     *   6.前端(1)获取信息,(2)渲染页面 --最终动态页面--> 客户端
     *
     *  缺点: 1.会话信息全部储存在客户端的浏览器中 服务器端不会存储任何会话信息[如用户标识],每次只能被动接收客户端接收请求时携带的会话信息
     *       2.安全性差,容易被伪造(信息完全暴露在请求头中)
     *  应用场景: 较小的功能,例如"记住密码"功能
     *
     * 2.Session
     *   过程:
     *    1.用户发起登录请求 -> 服务器接收 校验数据 数据正确
     *    2.服务器并不会直接返回客户端响应 而是借助数据库 在数据库中创建了一张表
     *      用于存储请求中的信息作为唯一标识 例如id字段中存储的是一段加密的长字符串
     *    3.数据库将id的值返回给Web服务器 Web服务器获取后并不会保存该数值 而是将响应连同id的值一同返回给客户端
     *    4.此时 id会保存在客户端的Cookie中 此时 客户端接收到的字段并不是请求中的原生的数据内容 而是数据库中的被加密的长字符串
     *    5.此时再次发起需要登录才可访问的请求 Cookie利用同域自动提交特性 将加密的字符串自动提交给服务端
     *      服务端继续借助数据库的表中查询该字符串对应的真正的原生信息 确认身份后才会继续查询请求对应的数据 并将查询到的结果返回
     *    6.服务端收到信息传递给前端 由前端进行渲染后 发送给客户端
     *
     *  特点: 1.依赖于Cookie
     *       2.在服务端侧也参与保存了部分用户信息并生成了加密的字符串 称为Session Key
     *       3.安全性较高,不容易被伪造
     *  缺点: 1.唯一标识是有有效期的 并且作为实体数据存放在服务器端 磁盘消耗极高
     *       2.后期维护性差 标识过期需要消耗额外资源清理
     *       3.查询效率低 随着用户体量的增加 即使建立索引也会在查询期间消耗大量时间
     *
     * 3.Token[主流:其中有很多种类 常用的为JWT<JSON Web Token>]
     */
    //Session
    /**
     * Spring MVC对Session的支持
     * 以下所有操作都是在服务器内存中完成的
     * 1.设置唯一标识:session.setAttribute(key ,value);
     * 2.获取唯一标识:session.getAttribute(key);
     * 3.删除唯一标识:session.removeAttribute(key);
     */
}
